Electronic data communication system with encryption for electronic messages

ABSTRACT

There is described an electronic data communication system in which encrypted mail messages for a recipient are sent in two parts: message data encrypted by a symmetric encryption algorithm using a session key and session key data encrypted by an asymmetric encryption algorithm using a public key associated with the recipient. If the recipient uses a webmail service to access the encrypted electronic mail message, the encrypted session key data is sent to a trusted third party server which has access to the private key of the user. The trusted third party server decrypts the encrypted session key using the private key of the user, and then sends the decrypted session key to a remote network device for decryption of the encrypted message.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.12/162,868, filed on Jan. 23, 2009, which is a U.S. National PhaseApplication of PCT International Application No. PCT/GB2007/000300,filed Jan. 30, 2007, which claims the benefit of British PatentApplication No. 0602131.5, filed on Feb. 2, 2006.

The above-noted disclosures are incorporated herein by reference intheir entirety.

BACKGROUND OF THE INVENTION

This invention relates to an electronic mail messaging system, and inparticular to a system for sending messages to and receiving messagesfrom a person electronically.

Electronic mail messaging is widely used. It is also known to encryptelectronic mail messages using public key cryptography in which anasymmetric encryption algorithm is used. In particular, a public keyassociated with the recipient of an electronic mail message is used bythe sender to encrypt the message. The resultant encrypted message canonly be decrypted by using a private key which is different from thepublic key and access to which is controlled by the recipient of themessage.

A problem with the asymmetric encryption algorithms utilised in publickey cryptography is that they are slow in comparison with symmetricencryption algorithms in which the same cryptographic key is used forencryption and decryption. This problem has previously been addressedfor electronic mail messaging by employing a so-called KEM-DEM approachin which an encrypted electronic mail message is formed by a KeyEncapsulation Mechanism (KEM) part storing a session key (which isunique to the message) encrypted using the public key of the recipient,and a Data Encapsulation Mechanism (DEM) part storing the electronicmail message encrypted by a symmetric encryption algorithm using thesession key stored in the KEM part as the cryptographic key. In thisway, the amount of decryption performed by the asymmetric encryptionalgorithm is reduced.

Public key cryptography works well when the recipient always uses aprivate computer, i.e. one which is under the control of the recipientand is not freely accessible to the public, to access electronic mailmessages.

Nowadays, “webmail” services are available which allow a user to use anycomputer connected to the internet to access electronic mail messagesstored in a mailbox in a remote network device. Such webmail servicesinclude services in which the mailbox of the user is permanently storedon a server operated by an electronic mail messaging service provider(for example the services provided by Hotmail and Yahoo) and serviceswhich allow accessing of messages temporarily stored by an electronicmail messaging service provider pending downloading to a permanent storeon a computer associated with the recipient. These webmail servicesallow a user to access electronic mail messages from a publiclyaccessible computer, for example at an internet café.

A problem with using publicly accessible computers to access electronicmail messages is that using a private key on a freely accessiblecomputer may compromise the private key, and accordingly the use ofconventional public key cryptography is not secure.

SUMMARY

According to the present invention, there is provided an electronic datacommunication system in which encrypted electronic mail messages for arecipient are sent using the KEM-DEM approach discussed above. When therecipient operating a first network device uses a webmail service toaccess an encrypted electronic mail message stored on a second networkdevice, the part of the message storing the encrypted session key issent to a third network device operated by a trusted third party whichhas access to the private key of the user. The third network devicedecrypts the encrypted session key using the private key of the user,and then the third party sends the decrypted session key to a remotenetwork device, which for example could be the first network device orthe second network device, where the DEM-part is decrypted using thesession key to allow the user to read the message. In this way, althoughthe trusted third party has access to the private key of the user, thetrusted third party does not have access to any encrypted messages.

In an embodiment, the trusted third party is the provider of the privatekey for the user. In this way, it is not necessary to divulge theprivate key to any additional party.

In a preferred embodiment, the public key of the asymmetric encryptionalgorithm for the recipient of the electronic mail message is derivedusing publicly available information including the identity of therecipient. This allows a sender to calculate the public key for arecipient, even if at the time of sending the electronic mail messagethe recipient does not have a private key. Such asymmetric encryptionalgorithms were first proposed by Shamir in 1984, were first derived bySakai and Kasahara in 2000, and have since been further developed by anumber of research groups.

DESCRIPTION OF THE DRAWINGS

An embodiment of the invention will now be described with reference tothe attached figures in which:

FIG. 1 schematically shows the main components of an electronic mailmessaging system according to the present invention;

FIG. 2 is a flow chart schematically showing operations performed by acomputer of a electronic mail message sender forming part of theelectronic mail messaging system illustrated in FIG. 1 to send anencrypted mail message;

FIG. 3 schematically shows the main components of an electronicmessaging service provider server forming part of the electronic mailmessaging system illustrated in FIG. 1;

FIG. 4 is a flow chart schematically showing operations performed by theelectronic messaging service provider server illustrated in FIG. 3;

FIG. 5 is a flow chart schematically showing in more detail operationsperformed by the electronic messaging service provider serverillustrated in FIG. 3 to display a selected message to a user;

FIG. 6 schematically shows the main components of a trusted third partyserver forming part of the electronic mail messaging system illustratedin FIG. 1;

FIG. 7 is a flow chart schematically showing operations performed by thetrusted third party server illustrated in FIG. 6; and

FIG. 8 is a flow chart schematically showing operations performed by analternative trusted third party server to generate a digital signature.

DETAILED DESCRIPTION

As shown in FIG. 1, an electronic mail messaging system has a sendingcomputer 1, associated with the sender of an electronic mail message,and a receiving computer 3, associated with the recipient of theelectronic mail message, interconnected by the internet 5. It will beappreciated that there are many other computers connected to theinternet 5, and any of those computers may form a sending computerand/or a receiving computer.

In this embodiment, the recipient of the electronic mail message is aclient of an electronic messaging service provider providing a webmailservice. In particular, the electronic messaging service provider has aserver 7 connected to the internet which stores electronic mail messagesfor the recipient. For the purpose of explanation, in this embodimentthe electronic messaging service provider server 7, hereafter called theEMSP server, will be allotted the fictitious Uniform Resource Locator(URL) www.privatewebmail.com, and the recipient will be allotted theelectronic mail address bob@privatewebmail.com.

Further, in this embodiment the recipient is a client of an encryptionkey authority which operates a server 9, hereafter called the trustedthird party server, which is also connected to the internet. For thepurpose of explanation, the trusted third party server 9 will beallotted the fictitious URL www.myencryption.com.

In this embodiment, the encryption key authority issues a public keycertificate providing a root public key K^(G) _(pub) for the encryptionalgorithm described in WO 03/017559, the whole contents of which ishereby incorporated herein by reference. According to this encryptionalgorithm, the public key K^(C) _(pub) for a client having an electronicmail address “client_ID” is given by:K ^(c) _(pub) =F(client_ID,K ^(G) _(pub))where F is a publicly available function. In this way, the public keyassociated with an electronic mail address ID can be calculated byanyone. However, the private key associated with the electronic mailaddress can only be calculated with knowledge of a root private keyK^(G) _(pri), which is kept secret by the encryption authority. Inparticular, the private key K^(C) _(pri) for a client having anelectronic mail address “client_ID” is calculated by the trusted thirdparty server 9 in accordance with the relation:K ^(C) _(pri) =G(client_ID,K ^(G) _(pri))where G is a function which is paired with F.

In order to send an encrypted electronic mail message to the recipient,the sending computer 1 uses the electronic mail address for therecipient and the root public key provided by the encryption authorityto calculate the public key for the recipient. The sending computer 1then generates an encrypted electronic mail message using the calculatedpublic key for the recipient in accordance with the process disclosed inWO 2005/050908, which is hereby incorporated herein by reference.

In summary, as shown in FIG. 2 after commencement, at S1, of theelectronic mail message encryption process in response to a userinstruction, the sending computer 1 generates, at S3, a digitalsignature and appends the digital signature to the message to form asigned message. In particular, the sending computer 1 processes themessage using a one-way encryption algorithm (also referred to as ahashing function) to generate a hash value which is representative ofthe message, and then encrypts the hash value using the private keyassociated with the user of the sending computer 1.

The sending computer 1 then generates, at S5, a session key K_(s) usinga random number generator. The sending computer 1 then encrypts, at S7,the signed message using the session key K_(s) as the cryptographic keyof a symmetric encryption algorithm to form the DEM-part of theencrypted electronic mail message. In particular, in this embodiment thesymmetric encryption algorithm used is the Advanced Encryption Standard(AES) algorithm.

For each recipient of the electronic mail message, the sending computer1 encrypts, at S9, the session key K_(s) using the public key K^(C)_(pub) for that recipient and combines the resultant encrypted sessionkeys to form the KEM-part of the encrypted electronic mail message. Inother words, if the electronic mail message is sent to three recipients,the KEM-part will include the three encrypted versions of the sessionkey K_(s), each version encrypted with the public key of a respectivedifferent recipient.

The sending computer 1 then combines, at S9, the KEM-part and theDEM-part to form the encrypted electronic mail message. Finally, thesending computer 1 sends, at S13, the encrypted electronic mail messageto the recipients.

As discussed above, the recipient associated with the receiving computer3 has an account at the electronic messaging service provider associatedwith the EMSP server 7. The encrypted electronic message is thereforedirected to the EMSP server 7 form where it can be accessed using anycomputer.

FIG. 3 schematically shows the main components of the EMSP server 7. Asshown, the EMSP server 7 has a processor 21, memory 23, an operatorinterface 25 and a network interface 27 interconnected by a bus system29.

In this embodiment, the operator interface 25 includes a keyboard forallowing an operator to enter data into the EMSP server 7 and a displayfor allowing an operator to read data produced by the EMSP server 7. Theoperator interface 25 also includes a CD-ROM reader/writer via whichdata stored on a CD-ROM 31 can be input into the EMSP server or data canbe written onto a recordable CD-ROM 31.

The network interface 27 receives data from remote devices, and outputsdata to remote devices, in the form of a network signal 33.

The processor 21 performs processing operations in accordance withprogram routines stored in the memory 23. These program routines may beeither stored during manufacture, or input to the EMSP server 7 via theoperator interface 25 or the network interface 27. The program routinesprocess data stored in the memory 23 and data received via the operatorinterface 25 or the network interface 27.

As those skilled in the art will appreciate, as is conventional thememory 23 is formed by different forms of memory, each having differentaccess times for retrieving data stored therein. For example, the memoryincludes hard drive regions with a comparatively slow access time and arandom access memory (RAM) regions having a comparatively fast accesstime. Conventional processing techniques are employed to improve speedof processing by caching data likely to be required into RAM in advance.

The memory 23 includes a region 35 storing the program routines used bythe EMSP server 7, a region 37 storing data and a region 39 providingworking memory.

In particular the program routines memory region 35 stores:

-   -   an Operating_System 41 for interfacing between the software        routines and the hardware components of the server 7;    -   a Web_Server 43 for providing web server functionality;    -   a Master_Control routine 45;    -   a Display_Message sub-routine 47; and    -   an Encryption_Algorithm routine 49 (in this embodiment the AES        encryption algorithm).

The stored data memory region 37 stores:

-   -   a client database 51 which stores user name, email address and        logon information (e.g. password) for each client;    -   a message database 53 storing messages including sender and        recipient electronic mail addresses;    -   webpage templates which are used by the Web_Server 43 when        forming web pages to be sent to a browser program; and    -   a message cache 57 for storing the DEM-part of encrypted        messages while awaiting the session key as will be described        hereafter.

When a client at a receiving computer 3 wishes to access electronic mailmessages stored in the EMSP server 7, the client uses a conventionalbrowser program on the receiving computer (for example MicrosoftInternet Explorer) to send an access request to the EMSP server 7 byentering the URL for the EMSP server 7 (i.e. in this embodimentwww.privatewebmail.com.

In response to receipt of the access request, the Master_Control routine45 initiates a web session. FIG. 4 is a flow chart showing the mainsteps performed in a web session.

After initiation, at S21, of the web session, the EMSP server 7performs, at S23, a logon procedure. In particular, the EMSP server 7sends logon web page data from the webpage templates 55 to the receivingcomputer 3 which causes a logon web page having data entry boxes for theclient to enter their electronic message address and logon information.The entered electronic message address and logon information is thensent by the receiving computer 3 to the EMSP server 7, which comparesthe received data with corresponding data stored in the client database51 to verify the identity of the client.

After the identity of the client has been verified, the EMSP server 7sends, at S25, web page data for a web page which displays a list of themessages for the client stored in the message database 53. Inparticular, the EMSP server 7 queries the message database 53 formessages for which the client is a named recipient, and enters dataincluding the sender field, the title field, the time sent field and themessage size field for the identified messages into a web page templatestored in the webpage templates memory region 55. In this embodiment,the title for each message forms a hyperlink, using conventional HTMLprogramming techniques, for accessing the corresponding message in themessage database 55. In addition to the list of messages, the web pagealso displays a logout button for ending the web session.

After sending the web page data for displaying the list of messages tothe receiving computer 3, the EMSP waits, at S29, for the next commandfrom the receiving computer 3. On viewing the web page displaying thelist of messages and the logout button, the client has the choice ofeither selecting a message for viewing by clicking on the title of theselected message, or pressing the logout button to end the web session.

On receiving a command from the receiving computer 3, the EMSP server 7checks, at S29, if the command corresponds to the selection of a messagefor display. If the command does not correspond to the selection of amessage for display (in other words the client has pressed the logoutbutton), the EMSP server 7 logs out, at S37, the client and the websession ends, at S39.

If the command does correspond to the selection of a message fordisplay, the Master_Control routine 45 initiates, at S31, theDisplay_Message sub-routine which will be described in more detailhereafter. This results in web page data for displaying the messagebeing sent to the receiving computer 3 together with a data fordisplaying a button for returning to the list of messages and a logoutbutton. The EMSP server 7 then waits, at S35, for the next command fromthe receiving computer 7.

On receipt of the next command, the EMSP server 7 checks, at S35,whether the command corresponds to the client at the receiving computer7 pressing the button requesting the list of messages to be re-displayedor pressing the logout button. If the command corresponds to a requestfor re-display of the list of messages, the EMSP server 7 re-sends theweb page data for the list of messages (S25). If the command correspondsto a request to logout, the EMSP server 7 logs out, at S37, the clientand the web session ends at S39.

The Display_Message sub-routine 47 will now be described in more detail.As shown in FIG. 5, on initiation, at S51, of the Display_Messagesub-routine 47 in response to the selection of a message for viewing,the EMSP server 7 parses, at S53, the selected image to check whether ofnot it is encrypted. In particular, the EMSP server 7 looks for a bytesequence within the selected message which is indicative of an encryptedmessage.

If the EMSP server 7 decides the selected message is not encrypted, thenthe EMSP server 7 sends, at S57, web page data for displaying themessage to the receiving computer along with the “return to inbox”button and logout button, and then the Display_Message sub-routine 47ends at S71.

If the EMSP server 7 decides the selected message is encrypted, the EMSPserver 7 extracts, at S59, from the KEM-part of the message the versionof the session key which has been encrypted using the public key of theclient at the receiving computer 3. The EMSP server 7 then, at S61,stores the DEM-part in the message cache 57 and calculates a URL linkfor directing the browser program of the receiving computer 3 to thetrusted third party server 9 and conveying the information needed by thetrusted third party server 9 to recover the session key and send thesession key to EMSP server 7. An example of such a URL is as follows:

-   -   https://www.myencryption.com/webmail/?user=bob@privatewebmail.com&key=fnf94338b3b8b43fb93n43n&date=20051229110300&returnurl=www.privatewebmail.com/ViewPPMessage?MessageID=12345

The format of this URL will now be explained:

https://www.myencryption.com/webmail/—establishes an encrypted websession with the trusted third party server and indicates thatdecryption of a session key is required;

user=bob@privatewebmail.com—indicates the identity of the client at thereceiving computer 3 to facilitate logging on at the trusted third partyserver 9;

key=fnf94338b3b8b43fb93n43n—provides the encrypted session key;

date=20051229110300—provides the date and time of day on which theselected message was sent so that the correct root private key isselected;

returnurl=www.privatewebmail.com/ViewPPMessage—gives the web address towhich the decrypted session key is to be forwarded; and

MessageID=12345—indicates the message within the message cache 57 whichis to be decrypted using the session key.

The EMSP server 7 then sends, at S61, web page data to the receivingcomputer 3 for displaying a web page indicating that the message is anencrypted message and requesting the client at the receiving computer 3to click on the calculated URL link. The EMSP server 7 then waits, atS65, for the decrypted session key.

The manner in which the trusted third party server 9 decrypts thesession key will now be described with reference to FIGS. 6 and 7.

As shown in FIG. 6, the trusted third party server 9 has a processor 71,memory 73, an operator interface 75 a network interface 77interconnected by a bus system 79. The functions of the processor 71,the operator interface and the network interface are the same as thecorresponding components of the EMSP server 7, and therefore will not bedescribed again in detail beyond stating that the operator interfaceallows data to be transferred to and from a CD-ROM 81 and the networkinterface 77 allows data to be transferred to and from remote networkdevices in the form of network signals 83.

The memory 73 includes a region 85 storing the program routines used bythe trusted third party server 9, a region 87 storing data and a region89 providing working memory.

In particular the program routines memory region 85 stores:

-   -   an Operating_System 91 for interfacing between the software        routines and the hardware components of the server 9;    -   a Web_Server 93 for providing web server functionality;    -   a Master_Control routine 95;    -   a Calculate_Private_Key sub-routine 97; and    -   a Decrypt_Session_Key sub-routine 99.

In this embodiment, the Calculate_Private_key sub routine and theDecrypt_Session_Key sub-routine utilise the encryption algorithmdiscussed in WO 03/017559 and accordingly will not be discussed indetail.

The stored data memory region 37 stores:

-   -   a client database 101 which stores user name, email address and        logon information for each client;    -   a key database which stores a table indicating the root private        key for each time period; and    -   webpage templates which are used by the Web_Server 93 when        forming web pages to be sent to a browser program.

In response to the signal sent by the receiving computer 3 when theclient at the receiving computer 3 clicks on the URL link provided bythe EMSP server 7, the trusted third party server 9 starts, at S81, aweb session. Firstly, the third party server 9 stores, at S83, theinformation attached to the URL and then authenticates, at S85, theidentity of the client. In this embodiment, authentication is performedby sending a web page requesting randomly selected components of thelogon information stored for that client in the manner adopted by manyonline banking websites. In this way, the requested logon informationchanges for each successive logon which protects against the enteredinformation being copied, either by looking over the shoulder of theclient at the receiving computer 3 or by intercepting the networksignals between the receiving computer 3 and the trusted third partyserver 9, and subsequently used to impersonate the client.

After authenticating the user, the trusted third party server 9initiates, at S87, the Calculate_Private_Key sub-routine 97 whichcalculates the private key associated with the client for decrypting theencrypted session key using the client identification information andthe root private key stored in the key database 103 for the time periodwhen the message was sent. The trusted third party server theninitiates, at S89, the Decrypt_Session_Key sub-routine 99 which uses thecalculated client private key to decrypt the encrypted session key.

The trusted third party server then calculates, at S91, a re-direct URLfor sending to the receiving computer 3. An example of such a re-directURL is as follows:

-   -   https://www.privatewebmail.com/ViewPPMessage?MessageID=12345&Key=4n9gn9gn94n9ghjy

The format of this URL will now be explained:

www.privatewebmail.com/ViewPPMessage?MessageID=12345 the return URLprovided by the EMSP server 7 which identifies the message within themessage cache 57 of the EMSP server 7 which is to be decrypted using thesession key; and

Key=4n9gn9gn94n9ghjy—the decrypted session key.

The trusted third party server 9 then sends, at S93, the re-direct URLto the browser at the receiving computer 3 and then ends, at S95, theweb session.

On receiving the re-direct URL, the browser at the receiving computer 3automatically sends a request for the URL, the request including thedecrypted session key, to the EMSP server 7.

Returning to FIG. 5, on receiving the decrypted session key, the EMSPserver 7 uses, at S67, the decrypted session key to decrypt the DEM-partof the message stored in the message cache 57 (the message beingidentified in the URL). The EMSP server 7 then sends web page data fordisplaying the decrypted message to the receiving computer 3, and theDisplay_Message sub-routine 47 ends at S71.

As described previously, the DEM-part of the encrypted message storesthe original message and a digital signature. In this embodiment, boththe original message and the digital signature are transmitted by theEMSP server 7 to the receiving computer 3. The integrity of the originalmessage (i.e. whether it is has been tampered with) is checked by thereceiving computer 3 using the digital signature in a conventionalmanner. In particular, the receiving computer 3 applies the same hashfunction as was used by the sending computer 1 when generating thedigital signature to form a test hash value, and decrypts the digitalsignature using the public key associated with the sender to generate areference hash value. If the test hash value is identical to thereference hash value, then the integrity of the message is verified.

As described above, neither the EMSP server 7 nor the receiving computer3 have access to the private key of the client. Therefore, even if thesecurity of the session key for a selected message is compromised, thesecurity of any of the other messages for the client stored by the EMSPserver is not compromised because those messages employ differentsession keys which can only be recovered with knowledge of the privatekey of the client. In this way, if the receiving computer 3 is in aninternet café or the like a client of the electronic messaging serviceprovider is able to view an encrypted message safe in the knowledge thatonly the security of that encrypted message may be compromised, a riskwhich is in any case inevitable if the message is to be viewed using apublicly accessible computer.

Further, the trusted third party server 9 does not have access to theDEM-part of the encrypted message. Accordingly, the trusted third partyis unable to view surreptitiously the contents of the electronicmessages for the client.

An advantage of the above-described embodiment is that the receivingcomputer requires only a conventional browser program. Accordingly,computers in internet cafes and the like can be used without the needfor any form of modification.

Modifications and Further Embodiments

In the above-described embodiment, the sending computer 1 generates adigital signature using the private key of the sender. However, if thesending computer 1 is publicly accessible (for example in an internetcafé) then this would compromise the security of the private key of thesender. In an alternative embodiment, in order to generate the digitalsignature the sending computer 1 generates the hash value, but thensends the hash value to the trusted third party server for encryptionwith the private key of the sender. In an embodiment, this is done bysending a request to the trusted third party server formed by a URLhaving the hash value and a return URL appended thereto. The operationsperformed by the trusted third party server on receipt of the URL withthe hash value appended will now be described with reference to FIG. 8.

The trusted third party server starts, at S101, a web session on receiptof the URL, and stores, at S103, the received URL information. Thetrusted third party server then authenticates, at S105, the user in thesame manner as described with reference to FIG. 7. After authenticatingthe user, the trusted third party server initiates, at S107, theCalculate_Private_Key sub-routine which calculates the private keyassociated with the user using user identification information and theroot private key stored in the key database. The trusted third partyserver then encrypts, at S109, the received hash value using thecalculated private key to generate a digital signature. The trustedthird party server then sends, at S111, the digital signature to thereturn URL and the web session ends at S113.

While in the described embodiment the original message is signed andthen encrypted, it will be appreciated that in an alternative embodimentthe original message could be encrypted and then the encrypted messagecould be signed.

In the above described embodiment, the trusted third party sends thedecrypted session key to the receiving computer 3, which automaticallyre-directs the session key to the EMSP server 7 where the message isdecrypted. In alternative embodiments, the DEM-part of the encryptedmessage is forwarded by the EMSP server 7 to the receiving computer 3for decryption at the receiving computer 3 using the decrypted sessionkey. This has the advantage that the EMSP server 7 does not have accessto the decrypted message. However, this also has the disadvantage ofrequiring that the receiving computer 3 has additional functionality inorder to perform the decryption.

In a further alternative embodiment, the decrypted session key and theDEM-part of the encrypted message are forwarded to a remote computerother than the EMSP server 7 and trusted third party server 9 fordecryption, and then the decrypted message sent to the receivingcomputer 3.

In the illustrated embodiment, when the EMSP server 7 detects anencrypted message the client is advised and a URL link is provided whichis clicked by the client to initiate decryption. This is advantageousbecause the client can decide whether the receiving computer issufficiently secure to receive the decrypted message. In an alternativeembodiment, a configuration option could be provided to redirect theclient directly to the trusted third party server 9 on detection of anencrypted message. This has the advantage of reducing the “click count”,but is less transparent to the client.

In the illustrated embodiment, on detecting an encrypted message theEMSP server 7 extracts from the KEM-part of the encrypted message justthe version of the session key encrypted with the private key for theclient. In an alternative embodiment the EMSP server could send theentire KEM-part to the receiving computer 3 for forwarding to thetrusted third party server 9. However, if the encrypted message has alarge number of recipients this would lead to a significant increase innetwork traffic.

In the illustrated embodiment, the trusted third party server 9 storesthe root private keys and calculates the private client key using theclient identity and the root private key. However, all that is necessaryis that the trusted third party server 9 has access to the clientprivate key. Accordingly, in alternative embodiments the trusted thirdparty server 9 could directly store the private keys for each client, oralternatively access the desired private key for a client from aseparate device.

In the illustrated embodiment, the asymmetric encryption algorithmdiscussed in WO 03/017559 is used. In this algorithm, the public key fora client is calculated using from the identity of the client and a rootpublic key. It will be appreciated that alternative algorithms with thesame overall functionality could be used, for example the algorithmdiscussed in “ID based cryptosystems with pairing on elliptic curve” byR. Sakai and M. Kasahara, Cryptology ePrint archive, Report 2003/054 andthe algorithm discussed in “An Efficient ID-KEM Based On theSakai-Kasahara Key Construction” by Chen et al, Cryptology ePrintarchive, Report 2005/224 (both of which publications are herebyincorporated herein by reference).

Further, the asymmetric encryption algorithm need not determine thepublic key for a client using the client identity, and any asymmetricencryption algorithm, for example the RSA algorithm, could be used.Similarly, although the illustrated embodiment uses the AES encryptionalgorithm to encrypt the DEM-part, other symmetric encryptionalgorithms, for example the DES algorithm, could be used.

While in the illustrated embodiment, an internet-based implementation ofthe invention has been described, it will be appreciated that theinvention could be used in computer networks which are not connected tothe internet. For example, an organisation may have an internal networkembodying the invention, in which case an employee of the inventioncould access electronic messages from any computer.

In the described embodiment, each client for the EMSP server 7 has ausername. It will be appreciated that in an embodiment the email addressfor the client could be utilised as the user name.

In the described embodiment, the receiving computer 3 is a conventionalpersonal computer. It will be appreciated that the receiving computer 3could be formed by other types of computer apparatus such as a thinclient or a personal digital assistant (PDA).

Although the described embodiment of the invention comprises computerapparatus and processes performed in the computer apparatus, theinvention also extends to computer programs, particularly computerprograms on or in a carrier, adapted for putting the invention intopractice. The program may be in the form of source code, object code, acode intermediate source and object codes such as in a partiallycompiled form, or in any other form suitable for using theimplementation of the processes according to the invention.

The carrier may be any entity or device capable of carrying the program.For example, the carrier may comprise a storage medium, such as a ROM,for example a CD-ROM or a semi-conductor ROM, or a magnetic recordingmedium, for example a floppy disk, or a hard disk. Further, the carriermay be a transmissible carrier such as an electronic or optical signalwhich may be conveyed via electrical or optical cable or by radio orother means.

When the program is embodied in a signal which may be conveyed directlyby cable or other device or means, the carrier may be constituted bysuch cable or other device or means. Alternatively, the carrier may bean integrated circuit in which the program is embedded, the integratedcircuit being adapted for performing, or for use in the performance of,the relevant processes.

Although in the described embodiments the invention is implemented usingsoftware, it will be appreciated that alternatively the invention couldbe implemented using hardware devices, or a combination of hardwaredevices and software.

The invention claimed is:
 1. A network server comprising: a data storeoperable to store encrypted electronic messages for a recipientcomprising i) encrypted message data corresponding to a message for therecipient encrypted by a symmetric encryption algorithm using a sessionkey and ii) encrypted session key data corresponding to the session keyencrypted by an asymmetric encryption algorithm using a public key ofthe recipient; a network interface operable to receive data from andtransmit data to remote network devices; and a processor operable,following receipt of a request to access an encrypted electronicmessage, to extract said encrypted session key data from the requestedelectronic message and forward the extracted encrypted session key databut not the requested encrypted electronic message to a remote networkdevice.
 2. The network server according to claim 1, wherein theprocessor is operable to generate link data comprising the encryptedsession key data and a network address for an encryption key server. 3.The network server according to claim 2, wherein the processor isoperable to generate link data further comprising a redirect networkaddress.
 4. The network server according to claim 2, wherein theprocessor is operable to generate link data further comprisingidentification data for the recipient.
 5. The network server accordingto claim 2, wherein the processor is operable to generate link datafurther comprising time data identifying a time period during which theencrypted electronic message was sent.
 6. The network server accordingto claim 2, wherein the link data comprises a uniform resource locator.7. The network server according to claim 6, wherein the processor isoperable to incorporate the generated uniform resource locator in webpage data.